Fix supported post types to solve missing Authors column #1036
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This solves #1033
I've been digging into this issue and there are a number of inconvenient truths that have led us here:
author
feature from the Quick Edit box, we have to trick WP into skipping it by usingremove_post_type_support()
for theauthor
feature.author
. So, when weremove_post_type_support()
for the coreauthor
feature, we're also removing post type support for CAP itself. (Aside: This whole setup kinda makes sense, because CAP will work, by default for new post types that supportauthor
, but also causes a number of chin-scratching scenarios.)supported_post_types()
method to clean up some testing and best practices issues. Unfortunately, it relies onpost_type_supports()
, so any calls to it, after the workaround in Item 1, fail to return the post type for the current edit page.This commit fixes that issue by changing the supported_post_types() method to get its value from the
$supported_post_types
property on the class. Thepost_type_supports()
call and post types filter are moved to aninit_supported_post_types()
method that only runs when the$supported_post_types
property is empty. This way, any call to$this->supported_post_types()
will not be influenced by the post type support fudging happening behind the scenes.Side note:
I think there should probably be a separate discussion about changing the CAP post type support feature name to
co-authors
. It would likely eliminate a number of unnecessary overlap issues. There would just need to be a function written to automatically addco-authors
support to any post type supportingauthor
. Then, we could possibly just removeauthor
support at that stage, and be able to remove some of the overlap workarounds in the rest of the plugin.Deploy Notes
I created this branch from the 3.6.0 tag, instead of the main
develop
branch, and that has made the Commits tab look a little weird. I'm not sure if this is the best way to handle it. Let me know if I should start over fromdevelop
and re-submit the PR.No new dependencies or complex considerations here. Just possibly a discussion to be had about whether this approach is the best solution.
Steps to Test